1. Field of the Invention
The present invention generally relates to protecting code and data on a computer system from other software on the system. More specifically, a new object identification label is provided in each cache line, the label identifying which, if any, secure object owns the data of that cache line, the data having been decrypted upon retrieval as an encrypted secure object from memory and placed in the cache, such that, if the data is indicated as owned by a secure object, the cache controller permits an access to that cache line data only by that secure object. If an access attempt is made by any other software, the cache line is invalidated and the encrypted version of the data is retrieved from memory and placed in that cache line, thereby ensuring that only the owner of the secure object has access to the secure object's decrypted data and/or code in the cache.
2. Description of the Related Art
The above-identified co-pending application introduced the notion of a ‘secure object’ comprising code and data on a computer system that is cryptographically protected from other software on the system, along with an exemplary computer architecture for supporting these secure objects.
FIG. 1 exemplarily shows such a computer architecture 100 that would implement the method described in this co-pending application, including microprocessor 101 having a CPU 102, L1 cache 103, L2 cache 104, interacting with external memory 105. Data and code in secure objects are stored in encrypted form in external memory 105 and, therefore, are inaccessible unless the encryption key is available for that secure object.
When a secure object executing on CPU 102 retrieves its encrypted information from external memory 105, the data and/or code of the retrieved secure object is decrypted in the crypto engine 106, using keys, temporarily stored in special crypto registers 107, The crypto engine 106 will again encrypt the secure object's data and/or code as it is written out to the external memory 105 via L2 cache 104. Thus, the secure object code and data remain decrypted (e.g., “in the clear”) only while within the CPU 102 and L1 cache 103.
Crypto key information, as well as mappings from handles to keys, are stored in a protected area 108 that cannot be accessed by software. When the CPU executes an esm instruction in this implementation, it takes the handle from the esm instruction, maps that handle to crypto key information and then loads the crypto key information into the special crypto registers in keys block 107.
Inside a Secure Object, private information is decrypted on the path from memory 105 to CPU 102 and encrypted on the path from CPU 102 to memory 105. The cryptography includes cryptographic integrity values to protect the integrity of a Secure Object's private code and data as well their confidentiality. Thus if an adversary or a software bug or software attack from another software module ‘tampers’ with an object's private code or data, the crypto hardware will generate a cryptographic integrity exception when the object next accesses that code or data. By contrast, when the secure object updates its private data, the Object's keys are used to update its cryptographic integrity values so that when the Object later accesses this data no integrity exception will occur.
The present application extends the concepts described in the above-referenced co-pending application by describing a cache structure that improves the performance of a computer system providing support for secure objects by adding components and features into the architecture shown in FIG. 1, as further described below.